[WIP] Add NVP (Non-Vascular Plant) Layer in CTSM - #3927
Conversation
269a477 to
e4b973e
Compare
| end do | ||
|
|
||
| ! [PORTED by Hui Tang: transfer NVP Beer's law absorptance from bc_out to surfalb_inst] | ||
| ! fabd_nvp_col/fabi_nvp_col are col-level; average equally over all patches in the site. |
There was a problem hiding this comment.
average equally over all patches in the site
Why? I would have thought these should be weighted by the area of the column on each patch.
| nvp_frac_sum = nvp_frac_sum + this%fates(nc)%bc_out(s)%nvp_frac_pa(ifp) | ||
| end do | ||
| if (nvp_frac_sum > 1.e-5_r8) then | ||
| surfalb_inst%alb_nvp_gnd_col(c) = surfalb_inst%alb_nvp_gnd_col(c) / nvp_frac_sum |
There was a problem hiding this comment.
Shouldn't the case of small nvp_frac_sum be handled?
|
It looks like you're never passing the nvp-specific if (trim(fates_stomatal_model) == 'ballberry1987') then
pass_stomatal_model = 1
else if (trim(fates_stomatal_model) == 'medlyn2011') then
pass_stomatal_model = 2
end if
call set_fates_ctrlparms('stomatal_model',ival=pass_stomatal_model)Is that intentional? There are, after all, parts of the FATES PR (e.g.) that look for the |
Also update test paramfiles.
use_nvp_temp_for_patch_gas_params. Default true to avoid disrupting Hui's work. However, this option should probably be deleted (and the FALSE behavior used) before merging this code---why should NVP get to ignore snow and surface water temps? It's going to be the PFT most affected by them!
| Only relevant when use_nvp=".true.". | ||
| </entry> | ||
|
|
||
| <entry id="use_nvp_temp_for_patch_gas_params" type="logical" category="physics" |
There was a problem hiding this comment.
Added hlm_use_nvp_temp_for_patch_gas_params option to avoid having the entire patch take NVP's temperature, which would be bad when NVP coexists with other PFTs.
However, before merging, this should probably be deleted, with the FATES code being updated only allow the "false" behavior. Even in an NVP-only run, why should NVP be allowed to ignore snow and surface water effects on temperature when other PFTs can't? Especially since temperature of NVP—the shortest PFT—would be most affected by those?
| ! Thermal conductivity of snow | ||
| ! Only examine levels from snl(c)+1 -> 0 where snl(c) < 1 | ||
| if (snl(c)+1 < 1 .AND. (j >= snl(c)+1) .AND. (j <= 0)) then | ||
| ! [PORTED by Hui Tang: skip j=0 when NVP occupies that layer; handled below] | ||
| if (snl(c)+1 < 1 .AND. (j >= snl(c)+1) .AND. (j <= 0) .AND. & | ||
| .NOT. (use_nvp .AND. jbot_sno(c) == -1 .AND. j == 0)) then | ||
| bw(c,j) = (h2osoi_ice(c,j)+h2osoi_liq(c,j))/(frac_sno(c)*dz(c,j)) |
There was a problem hiding this comment.
I'm running into a divide-by-zero error when use_nvp is true but there is no NVP layer present. jbot_sno(c) == -1 evaluates to false, so the NOT is satisfied, and this conditional block gets entered. But then dz is zero, causing divide-by-zero in the calculation of bw.
Was failing, and no other FATES test does it. For more details, see: ESCOMP#1902 (comment)
2 participants
Description:
This PR introduces a physically explicit representation of non-vascular plants (NVP; e.g., moss and lichen) in CTSM–FATES and its biophysical effect by assigning them to a dedicated vertical layer in CTSM, and a NVP PFT in FATES. The core architectural decision is to use layer 0 of the soil-snow layer structure to accommodate NVP and its growth (i.e., changes in height) when it is present. This layer integrates consistently into CLM’s radiation (under snow), thermal, and hydrology schemes, while coupling to FATES (NGEET/fates#1556) for canopy radiation (without snow) and photosynthesis (see the following call graph).
Note: The implementation is not fully ready yet and is still open for discussion.
Key implementation details in CLM:
NVPWaterBalance_Column.Collaborators:
@rosiealice
Expectation of Answer Changes:
This PR is expected to produce answer changes when NVP is active and NVP layer is present:
No answer changes are expected when NVP is disabled.
Description of generative AI usage
Claude code has been used for porting changes into the new CTSM version and designing the overall structure. The call graph is also generated by Claude code.
Any User Interface Changes (namelist or namelist defaults changes): Yes.
Does this create a need to change or add documentation? Yes